1. The Field of the Invention
The present invention is generally related to binding messages to communication aspects in a distributed system. More specifically, the present invention provides a developer with an automated, user friendly way of constructing binding objects that can be used to create a runtime communication channel in order to apply communication aspects to messages when transferring them between endpoints.
2. Background and Related Art
Computer systems and related technology affect many aspects of society. Indeed, the computer system's ability to process information has transformed the way we live and work. Computer systems now commonly perform a host of tasks (e.g., word processing, scheduling, database management, etc.) that prior to the advent of computer systems were performed manually. More recently, computer systems have been coupled to one another to form computer networks over which the computer systems can communicate electronically to share data. Service oriented systems (e.g., Web Services) have been a driving force in advancing such communications between computer systems and is turning the way we build and use software inside-out.
Service oriented architectures let applications share data, and—more powerfully—invoke capabilities from other applications without regard to how those applications were built, what operating system or platform they run on, and what devices are used to access them. Typically, these systems are invoked over the Internet by means of industry-standard protocols including SOAP (Simple Object Access Protocol), XML (extensible Markup Language), UDDI (Universal Description Discovery Integration), WSDL (Web Service Description Language), etc. Although these services remain independent of each other, they can loosely link themselves into a collaborating group that performs a particular task.
Often, electronic communication in a service oriented network includes a client computer system (hereafter referred to as a “client”) requesting access to a network service(s) (e.g., Web Services) at a server computer system (hereinafter referred to as a “service”). Accordingly, the client sends a request to the service for particular access to its system resources, wherein if the client is authorized and validated, the service responds, e.g., with a response message providing the desired information. Of course, other message exchange patterns between a client and a service are available and include simple singleton messages as well as more sophisticated multi-message exchanges like, e.g., notifications, solicit-response, pub-sub patterns, polling, kick-push, queuing and others.
Service oriented concepts (e.g., addresses, bindings, and message interaction patterns) describing a service can be included in a programming model. The programming model can then be accessed by service consumers that desire to communicate with the described service. Generally, service oriented concepts (e.g., a programming model) are described in accordance with some service oriented standard, such as, for example, Distributed Component Object Model (“DCOM”), Common Object Request Broker Architecture (“CORBA”), or Web services. Web services can be further defined in accordance with various Web services specifications, such as, for example, Web Services Description Language (“WSDL”), Web Services Policy Framework (“WS-Policy”), etc.
Service oriented standards like WSDL provide an overall wrapper or specification for describing contracts (e.g., WS contracts) in a common or standard language. Such specifications make it easy for developers and developer tools to create and interpret contracts. Although such Network Protocol Description Languages (hereinafter referred to as “NPDL”) have extensive tooling suites, which in large part accounts for their popularity, there are currently several shortcomings and downfalls to such standards.
For example, distributed applications are typically rigid in their programming models allowing only one programming model that is tightly coupled to their service runtime. Accordingly, for compatibility, a client runtime (e.g., at a service consumer) is typically required to utilize a client program or module developed in accordance with the same programming model as the server runtime. For instance, if a service was developed using separate interfaces for request and reply messages or using particular security mechanisms, the service consumer must implement those as well. Failure to use a client program or module developed in accordance with the same programming model can prevent a client runtime from communicating with service runtime.
Further, current NPDLs bind a contract to a limited set of communication aspects which include a message exchange pattern (e.g., one-way, request-reply, pub-sub, duplex, etc.), a message encoding or format (e.g., SOAP envelope) and a type of transport for exchanging the message with a service (e.g., HTTP (HyperText Transport Protocol), FTP (File Transfer Protocol), SMTP (Simple Message Transfer Protocol), TCP (Transmission Control Protocol), UDP (User Datagram Protocol), SMS (Short Message Service), SNA (Systems Network Architecture), GPRS (General Packet Radio Service), etc.). Additional communication aspects (e.g., security, reliability, context flow, transaction flow, logging options, connection throttling options, etc.) must be specified in other documents (e.g., WS Policy) or configured out of band on both the client and service side.
Due to the wide spread distribution of communication aspects sprinkled throughout the system, there is some chance that through human error a service description document or configuration is not a complete, accurate description of the corresponding service. Due, however, to the rigid coupling between programming model and service runtime, the lack of even one communication aspect or configuration option defined by a service can result in an incompatible client runtime.
In addition, because not all communication aspects are provided for in NPDLs, both the client and the service must have a significant amount of code within each application in order to utilize and maintain communication aspects. For instance, in the case of a security context the client needs to have code that will: (1) recognize that communications with the service application must use a security context token; (2) request such token from a token issuer; (3) provide the appropriate information within the request; (4) save the security context token for future communications; and (5) reference the appropriate base token and shared secret when receiving communications from the service using the security context token. Likewise, the service application must be coded such that when receiving secured messages from the client based on the security context token, the service application must be able to: (1) identify the base token; (2) determine the appropriate session key associated with the base token to decrypt the message; (3) save the security context token; and (4) reuse the security context token to encrypt messages and sign them for securely delivering them to the client.
Because such communication aspects for security and other semantics must be coded in both the client and service applications, there is little, if any flexibility, nor ease in extending the system. For example, if it may be desirable to extend the service oriented system to enable it to use different types of security context tokens or have different reliability options; however, doing so would require another large amount of code in the service application and as well as rewriting existing code. Of course, security context may also be established at the transport level using, e.g., HTTPS. This solution, however, also does not allow any flexibility or ease in extending the system since the semantics are predefined by the specification. Further, because application developers are typically not experts in specific communication aspects, there are security concerns, reliability concerns, as well as performance, stress, or other robustness factors. Moreover, the large number of permutations and combinations of all of these communication aspects becomes unwieldy and difficult to fully appreciate the benefits of the various combinations.
Accordingly, there exists a need for a user interface that gives a developer an automated and user friendly way of binding messages to a wide array of communication aspects. This user interface should be capable of generating standardized tools that can be used by both client and service for consistency purposes. Moreover, a need exists for describing a list of commonly used and compatible communication aspects for limiting the number of possible permutations for binding protocols. In addition, the various communication aspects, as well as the commonly used combinations, should be fully flexible, extensible and pluggable.